Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multi arch built by github actions #35

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

wouldgo
Copy link

@wouldgo wouldgo commented Mar 19, 2022

Hi,

for my personal needs I adapted the repo to be built for amd64 and arch64 architectures by the action tags.yaml. The only contraint is on tag name to be on the form of ^v\d{1,}\.\d{1,}\.\d{1,}$ as stated in the action file.

Hope this can be helpful even for others.

Open to dicuss improvements or changes.
Dario.

PS I did a mistake on adding the whole musl source into _out folder and removing this from history git rewrote the whole history. Nothing from the past changed but I hope this is fine...

@aarongable
Copy link

Hi, and thanks for the contribution!

As you mention, it looks like the repo history got a bit messed up. I think the following set of git commands should get this PR into a "clean" state:

git checkout -t origin/main -b multi-arch-new  # create a new branch to hold the fixed commits
git cherry-pick  multi-arch~11..multi-arch~2   # copy over just the new commits (leaving out the merge and the recreation of `b4edb2be`)
git checkout multi-arch                        # switch back to your working branch
git reset --hard multi-arch-new                # set it to point at the new clean commits we just created

Then you can re-upload the PR (you'll need to use --force to overwrite what's already here) and delete the temporary multi-arch-new branch.

All taht said, we'd be happier building binaries, rather than whole docker containers, using this new automation. We consume this repository as source ourselves (and encourage others to do so), but recognize that it may be useful to others to have binaries directly available. But it's much easier to wrap a container around a binary than to extract a binary from a container, so we'd prefer it if this infrastructure simply produced executables rather than whole containers.

Go has robust cross-compilation support already, so you should be able to do that without spinning up a container to do it in. Simply setting GOARCH=arm64 go build ./... should work, unless something really funky I'm not aware of is going on.

Finally, we'd love to hear more about your use-case for these binaries, so we can be better maintainers!

Thanks again :D

@wouldgo
Copy link
Author

wouldgo commented Mar 22, 2022

Hi,

so I'll take care of cherry picking the commit (did not thought about it 😵‍💫).

Anyway I have a k3s home cluster with a statefulset made by 2 containers, unbound and stubby (for delivering a DoT at my home), and I wanted to measure the stats putting this exporter as a sideacar.

This is why I did use the approach of building the container.
Agreed that the action approach can be used to compile also the binaries without the containerization.

Hope this scenario can be usefull.
See you soon with the cherry-picked commit on top main

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants